1. Field of the Invention
The field of the invention relates to data processing and in particular to performing diagnostic operations on data processing apparatus.
2. Description of the Prior Art
It is known to provide data processing systems with diagnostic mechanisms which can be used to perform diagnostic operations (e.g. software and hardware fault identification and analysis (debug)) upon the data processing systems so as to assist in the development of hardware, operating systems, application programs, overall system designs and the like.
When analysing a data processing system, an external debugger may be used which comprises a debug program run on a host system that is connected to the target system to be analysed such that control signals specifying diagnostic operations to be performed on the system are passed from the host to the system.
External debuggers involve a debugger being connected to the target via an external port which is then used to program the debug hardware. The processor is configured such that debug events that are considered as diagnostic exceptions cause entry to a special debug state in which the data processing apparatus is interrogated and controlled by the external debugger.
Alternatively there may be a self-hosted debug system where debug monitor software is executed on the target being debugged. In such a case, the processor is configured such that debug events cause diagnostic exceptions that interrupt the software being debugged and pass control to the debug monitor software. A useful diagnostic tool is the ability to control a processor to single step through a program. This allows the state of the system to be analysed at each step of the procedure if required. In the single step mode the processor will execute an instruction and then a diagnostic exception will be taken and control will pass to debug software which can analyse the state of the processor. When a return from the diagnostic exception occurs then the processor will execute the next instruction whereupon a next diagnostic exception will be taken. In this way the debug software may control the processor to single step through a whole program or just through a portion that is of interest to the person analysing the system.
One problem that can arise when single stepping through code is if code is encountered that has a different execution path if an exception is taken between instructions. This can be particularly difficult if the different execution path involves an infinite loop. For example an instruction that tries to claim an exclusive monitor. If the code succeeds in claiming the exclusive monitor then it has exclusive access to a particular storage location and can store data there. Thus, in order to claim the exclusive monitor, a special load-exclusive instruction is used that both returns the current value of the storage location, and sets the exclusive monitor so as to indicate that the instruction stream currently being executed has exclusive access to particular storage locations. A store exclusive instruction can then be executed to store data to such a storage location. However, in the case of single stepping through code, once the exclusive monitor has been claimed by setting it, a diagnostic exception is taken and on return from this exception the exception handler will clear the exclusive monitor. This is because when an exception is taken the exception handler may not return to the code it was previously executing but will return to different code, and thus the exclusive monitor should be cleared as the next instruction stream to be executed should not have exclusive access to the storage location.
However, in single step having cleared the exclusive monitor then when the store exclusive instruction is reached it will fail which triggers return to the steps to claim the exclusive monitor, which will claim it and then have it cleared by the exception return and thus, in single step the store exclusive instruction will repeatedly fail and the program will never progress.
An example of code with this problem is given below
LoopLDREXR5, [R1] ; read lock (load-exclusive)CMPR5, #0 ; check if 0STREXEQR5, R0, [R1] ; attempt to store new valueCMPEQR5, # ; test if store succeededBNELoop ; retry if not
The problem with an exception handler clearing the exclusive monitor or lock location on return from a diagnostic exception and causing an infinite loop in this code when in step mode is known and addressed in GDB for Power and MIPS architectures by scanning an instruction prior to stepping through it in order to determine the location of blocks such as these. Once they have been identified a step until command is used such that a breakpoint is set in this case after the store exclusive instruction and no exception is taken between the instructions in this block and the lock location is not cleared by the exception handler.
A disadvantage of this solution is that all code needs to be examined to identify the problem code. This has significant overhead, as the diagnostic system will need to go to the operating system that is controlling execution of the instruction stream and ask it to fetch the code in order to be able to analyse it. If the diagnostic apparatus is remote from the processing apparatus the overhead will be particularly high.
Power discloses the use of a syndrome register which stores information about the state of the processor when a step exception (called trace exception in the Power architecture) is taken to allow return to that state. One piece of information that it stores is an indicator indicating that a load exclusive instruction has been executed and that a location is locked prior to taking the exception. There is no information on how this value is used.
It would be desirable to be able to diagnose code using single step procedures even where there is code of a type whose execution path is changed by the taking of an exception between instructions.